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20 BACKGROUND OF THE INVENTION 



1. Field of Invention 

The invention relates generally to computer systems. More particularly, 
methods and apparatus for providing an authentication-technology independent, non- 
25 programmatic method and apparatus for bootstrapping a user database from the WEB 
tier. 
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2. Description of Relevant Art 

Most web application servers provide applications with programmatic access 
to one or more authentication mechanisms. Applications, which run on these servers, 
use the APIs provided by the application server to authenticate their users. For 
5 example, servers implementing NSAPI define a set of "AuthTrans-class functions," 
including "basic-auth" which " calls a custom function to verify user name and 
password". Servers implementing Microsoft's IS API provide an API call called 
"GetServerVariable" that allows access to the authentication type (such as "Kerberos, 
user,SSL/PCT, Basic, [or] integrated Windows authentication") and authentication 

10 information, such as certificate information or usemame and password. Other servers 
handle this in a similar fashion. 

Many application servers also provide a programmatic account creation 
interface such that first-time users may use an application to create accounts for 
themselves. This ability to auto-register with an application is important to the 

15 viability of web applications as it provides an automated path past the barrier 

represented by lack of an accoimt without requiring the assistance of administrative 
personnel within the enterprise. An application, which uses the accoimt creation 
interfaces, is easily able to customize many aspects of the user registration process 
including look and feel and the collection of any ancillary (profile) data associated 

20 with the user. 

Java2™ Platform, Enterprise Edition (J2EE) application servers take a new 
approach to the implementation of security related fimctionality, in that security 
fimctionality such as that related to user authentication or account creation is done on 
behalf of the application by an enhanced application server referred to as a container. 
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The seciirity functionality performed by the container on behalf of the application is 
defined external to the application implementation. This approach frees application 
component providers from implementing complex security fimctionality and ensures 
that application components do not become encumbered by calls that would limit 
their ability to be deployed in diverse operational environments. 

Therefore, what is desired is a non-API based mechanism for bootstrapping a 
user database that is consistent with the goals of the J2EE platform and which has 
many of the same advantages as an API approach. 
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SUMMARY OF THE INVENTION 
A non-API based mechanism for bootstrapping a user database that is 

consistent with the goals of the J2EE platform and which has many of the same 

advantages as an API approach is disclosed. 
5 In one embodiment, a method for bootstrapping a user database associated 

with an application from an application server in a browser/server environment is 

disclosed. A user information request page is formed by the application, which is 

then sent to a user. The user returns a filled out user information request page to the 

application server which then extracts security data from the filled out user 
10 information page. The application server then bootsfraps a user accoxmt in the user 

database based upon the exfracted security data. 

In another embodiment, an apparatus for bootstrapping a user database 

associated with an application from an application server in a browser/server 

environment is disclosed. 
15 In yet another embodiment, a computer program product for bootstrapping a 

user database associated with an application from an apphcation server in a 

browser/server environment is disclosed. 

These and other advantages of the present invention will become apparent 

upon reading the following detailed descriptions and studjdng the various figures of 
20 the drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The invention, together with fixrther advantages thereof, may best be 
understood by reference to the following description taken in conjunction with the 
accompanying drawings in which: 

Fig. 1 shows an unregistered user requesting a registration page in a 
browser/server system in accordance with an embodiment of the invention. 

Fig. 2 shows the browser/server system of Fig. 1 whereby the user responds to 
a received registration page. 

Figs. 3-5 illustrate flowcharts detailing a process for bootstrapping a user 
database from the Web tier in accordance with an embodiment of the invention. 

Fig. 6 is a diagrammatic representation of a general-purpose computer system 
suitable for implementing the present invention. 

Fig. 7 is a diagrammatic representation of a virtual machine suitable for 
implementing the present invention. 
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DETAILED DESCRIPTION OF THE EMBODIMENTS 



The present invention will now be described in detail with reference to a 
few preferred embodiments thereof as illustrated in the accompanying drawings. 
In the following description, nximerous specific details are set forth in order to 

5 provide a thorough understanding of the present invention. It will be apparent, 
however, to one skilled in the art, that the present invention may be practiced 
without some or all of these specific details. In other instances, well known 
process steps and/or structures have not been described in detail in order to not 
unnecessarily obscure the present invention. 

10 In accordance with one embodiment of the present invention, there is provided 

a non-API based mechanism for bootstrapping a user database that is consistent with 
the goals of the J2EE platform and which has many of the same advantages as an API 
approach. Broadly speaking, without the requirement of an API, the invention 
enables an unauthenticated user to create a new account via a web interface (by 

15 providing a usemame, password, and password verification, for example). This is 

desirable so that a system administrator need not be present to create user accounts for 
applications in which it is reasonable to allow users to create their own accounts. The 
invention also provides for a deployer of a web application (instead of the application 
developer) to configure the security environment. This is desirable because it takes 

20 the burden of implementing security correctly out of the application developer's 
hands. Thereby promoting reusability of security-related code in the application 
server, and increasing the chance that security is implemented correctly. It also 
allows a single appHcation to operate in more environments. 

The invention fiirther provides for flexibility to support multiple and/or new 

25 authentication technologies without change to the existing web application code. This 
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is desirable because it enables the deployer more flexibility in choosing an 
authentication technology appropriate to the deployment environment, and it allows 
web applications to vary independently of available authentication technologies. A 
NSAPI or ISAPI application, for example, would need to be altered to support a new 

5 authentication technology in this absence of this solution. 

In addition, the invention enables appearance customization of these web 
applications by the application developer. Web applications vary greatly in 
appearance and look and feel. In many cases, it would not be acceptable to sacrifice 
user appearance customization in exchange for the benefits previously described. 

10 Furthermore, the invention enables error handling for accoimt creation and 
maintenance by the application developer. This is desirable because the web 
application may need to perform special processing in the event of an account 
creation error. When applicable, the invention enables a user to change passwords via 
a web interface (by providing a usemame, old password, new password and password 

15 verification, for example). This is desirable so that a system administrator need not 
be present to change user passwords for applications in which it is reasonable to allow 
users to change their own passwords. 

In order to satisfy these requirements, this invention uses the concept of 
"pass-through server-provided form targets" as a non-programmatic method for 

20 bootstrapping a user database from the web tier. A "form target," used in this context, 
is the submission destination of an HTML form, submitted via HTTP (typically this is 
called an "action" in HTTP). The "form target" is usually the name of a CGI script, or 
an alias to an ASP, Servlet or JSP on the server, which will handle a form request. 
When the user submits a form via HTTP, the web browser will redirect the user to the 

25 given form target. A "server-provided form target" is a form target that is provided 
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by the server instead of by the web application. This form target is accessible to any 
application deployed on the server, and therefore can be reused. Typically, when a 
user submits a form to a "server-provided form target," the application server has 
some way of knowing the page to redirect the user to after processing the form 
5 submission. 

In order to facilitate imderstanding of the following detailed description, a 
brief sunmiary of the terminology used herein is presented. Accordingly, the 
following terminology is used in this description: 

1) an application developer is that party responsible for creating a web 
10 appUcation; 

2) an application server is a host for applications, providing various 
services such as security services; 

3) a deployer is the user or users responsible for installing a web 
application on an application server and configuring the web application for the target 

15 environment; and 

4) a web application is a multi-tiered program that is being run in the 
context of an appHcation server that utilizes a web front-end. 

Although the invention will initially be described in terms of a multithreaded, 
object oriented computing system implemented using HTTP requests and responses, it 
20 should be noted that the present invention can be used in any system that is capable of 
handling well defined requests and responses across a distributed network. 

It should be noted that although the invention is also described in terms of the 
Internet, any distributed network could be suitably employed to implement any 
desired embodiment of the invention. It is one of the advantages of the invention that 
25 it is well suited for low bandwidth systems capable of executing client side 
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applications. Such low bandwidth systems include, but are not limited to: virtual 
private networks direct serial connections across telephone lines ("BBS systems"), 
and LANs and WANs regardless of network protocol. 

When implemented in a network using the HTTP protocol, such as the 
5 Internet, when an end user (i.e., client) desires to run an application within a browser 
environment, the end user generates an HTTP request for a resource identified by a 
URL (universal resource locator). In one implementation, this request is transmitted 
by way of a distributed network, such as the Internet, to a server computer. 

The invention will now be described in terms of a browser resident in a client 
10 computer that is typically used to execute an e-commerce application. It should be 
noted, however, that any applications requiring data processing in a highly interactive 
environment can also be implemented using the invention, and the invention therefore 
should not be construed as being limited to e-commerce applications. It should also 
be noted, that the invention is well suited for any low bandwidth system in which user 
15 interactivity is a prime consideration. 

Referring now to Fig. 1, a browser/web application server system 200 in 
accordance with an embodiment of the invention is shown. It should be noted that in 
terms of the described embodiment, a Web application server is an arrangement 
whereby an application server combines or works with a Web server such that the 
20 Web browser supports an easy-to-create HTML-based front-end for the user. The 
Web server provides several different ways to forward a request to an application 
server and to forward back a modified or new Web page to the user. These 
approaches include the Common Gateway Interface (CGI), Active Server Page (ASP) 
and the Java Server Page (JSP). 
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Accordingly, the system 200 includes a client computer 202 coupled to an 
application server 204. Typically, the application server 204 is part of a distributed 
interconnected computer network 205 such as the Internet, but can also be part of a 
private wide or local area network (WAN/LAN) utilizing HTTP protocols, sometimes 

5 referred to as an intranet. It is one of the advantages of the invention that the 
interconnected computer network can be any low bandwidth system. In order to 
facilitate communication between the various users and/or computers that form the 
network 205, the client computer 202 utilizes the graphical user interface resources 
presented by a Web page (sometimes referred to as an HTML page) 206 resident in a 

10 browser 208, most of which are obtained by various HTTP requests. When a user 

desires to download a particular HTML page 206 from the application server 204, the 
browser 208 generates an HTTP request having a URL for the requested page 206 
that includes information related both to the location of the Web application server 
204, and to the location within the application server 204 where the page 206 is 

15 located. 

In order, therefore, to register as a new user using the web browser 208, an 
unregistered, unauthenticated user generates a user registration page request 210 and 
forwards it to the application server 204. In the described embodiment, the 
application server 204 embeds a set of security registration data requirements 212 
20 (e.g. usemame, password, realm, etc.) in the request 210 and forwards the request 210 
to a user registration page 214 in a web application 216. In some cases, the security 
data requirements include, for example, a usemame, a choice of reahn (i.e.. East 
Coast, West Coast, Central, etc.), a user password and a password confirmation. It 
should be noted that in a particular Java'^'^ based implementation the security 
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registration data requirements can be passed, for example, as an attribute in a 
ServletRequest object if the application uses the Java Servlet API. 

In the described embodiment, the user registration page 214 then puts together 
a new user data form 218, merging the security registration data requirements 212 

5 along with various user profile registration data requirements 220 (e.g. phone nimiber, 
city, state, zip) from the application 216. It should be noted that the form 218 is 
consistent with the look and feel of the web application 216 such as for example, aa 
HTML type form, an XML type form, etc. In some embodiments, the apphcation 
server 204 provides a way of turning the requirements 212 into a set of HTML tags, 

1 0 for example, to be used in the form 218, such as providing a page to be included 
within an HTML form. This would reduce the complexity of applications that don't 
care as much about the look and feel of the security portions of the user registration 
form. 

In the described embodiment, the web application 216 also includes a success 
15 file (or "success target") 222 that informs the application server 204 the page to 
redirect the user in the event of successful account creation. In addition, the web 
application 216 includes a failure file (or "failure target") 224 that informs the 
application server 204 the page to redirect the user in the event of failed, or 
unsuccessful, account creation. In particular, the targets 222 and 224 typically take 
20 the form of URLs, the exact name of which can be specified by the application server 
204. Once the form 218 is configured, the web application 216 sends the form 218 to 
the user. 

Referring to Fig. 2, once the user fills out the form 218 with the appropriate 
information, the user submits the form 218 back to a pass-through server-provided 
25 form target 226 in the application server 204. The application server 204 then 
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retrieves requested security data 228 it requires to create a new account and attempts 
account creation in a user data base 230. Upon successful account creation, the 
success target 222 is invoked. However, if an error occurs during account creation, 
the failure target 224 is invoked. It should be noted that all form submission data is 

5 forwarded to whichever of these targets is invoked. When the success target 222 is 
invoked, the application 216 Avill typically verify and store user profile data in a user 
profile database 232 and send back a success page 234 suitable for a registered user. 
However, when the failure target 224 is invoked, the application 216 will typically 
send back a failure page 236 suitable for an unregistered user. 

10 In a Java™ based system, if an error occurs during account creation, the 

failure page 236 returned to the user can be the output of the JSP, Servlet, etc. 
specified in the failure target 224. This would normally be a web-apphcation 
provided page. The application server 204 passes in all the user profile information as 
if the user submitted the form directly to the error target. At this point, the web 

15 application 216 would likely indicate what went wrong, and allow the user to fix it, 
possibly pre-filling any form fields with the information the user provided on the 
previous form submission and indicating which fields may have problems. 

In a Java™ based system, if the account creation was a success, the success 
page 234 returned to the user can be the output of the JSP, Servlet, etc. specified in 

20 the success target 222. This would also normally be a web-application provided page. 
The server 204 passes in all the user profile information and security information as if 
the user submitted the form directly to the success target 222. At this point, the web 
application 216 would likely check the user profile information to ensure it is valid. 
If it were not valid, the application 216 would not need to re-prompt for security 

25 information since the server 204 already created the user's account. 
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It should be noted that all future form submissions would not need to be made 
to the pass-through server-provided form target 226 and could, instead, be submitted 
directly to a web-application-provided page. If user profile information is valid, the 
web application 216 can enable the user's account. It should be noted that a set of 

5 initial privilege attributes should be associated with newly created users. 

Figs. 3-5 illustrate flowcharts detailing a process 400 for bootstrapping a 
user database from the Web tier in accordance with an embodiment of the invention. 
The process 400 begins at 402 by an unregistered and unauthenticated user requesting 
a user registration page from a web application using a browser. At 404, an 

10 application server provides a set of security registration data requirements to the web 
application consistent with the user request. Next, at 406, the web application creates 
a request form by merging the security registration requirements from the application 
server with a user profile database. The web application then forwards the form to the 
user at 408 who fills out the form and sends the filled out form back to a pass-through 

15 server target on application server at 410. The application server then retrieves from 
the user response any security data required to create an account at 412, which is 
attempted at 414. Based upon the retrieved data, a determination is made at 416 
whether or not a new account has been successftilly created. If a new account has not 
been successfully created, then in Fig. 4, a failure target is invoked at 502 and form 

20 submission data is forwarded to the failure target at 504. At 506, the web application 
sends back a page to the user suitable for an unregistered user. 

If, however, at 416, it has been determined that a new account was created, 
then in Fig. 5, a success target 602 is invoked and form submission data is forwarded 
to the success target at 604. The web application then verifies and stores user profile 
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data at 606 and at 608, the web application sends back a page to the user suitable for a 
registered user. 

Fig. 6 illustrates a typical, general-purpose computer system suitable for 
implementing the present invention. The computer system 1030 includes at least one 

5 processor 1032 (also referred to as a central processing unit, or CPU) that is coupled 
to memory devices including primary storage devices 1036 (typically a read only 
memory, or ROM) and primary storage devices 1034 (typically a random access 
memory, or RAM). 

Computer system 1030 or, more specifically, CPUs 1032, may be arranged to 

10 support a virtual machine, as will be appreciated by those skilled in the art. One 

example of a virtual machine that may be supported on computer system 1030 will be 
described below with reference to Fig. 7. As is well known in the art, ROM acts to 
transfer data and instructions uni-directionally to the CPUs 1032, while RAM is used 
typically to transfer data and instructions in a bi-directional manner. CPUs 1032 may 

15 generally include any number of processors. Both primary storage devices 1034, 
1036 may include any suitable computer-readable media. A secondary storage 
medium 1038, which is typically a mass memory device, is also coupled bi- 
directionally to CPUs 1032 and provides additional data storage capacity. The mass 
memory device 1038 is a computer-readable medixmi that may be used to store 

20 programs including computer code, data, and the like. Typically, mass memory 

device 1038 is a storage medium such as a hard disk or a tape which generally slower 
than primary storage devices 1034, 1036. Mass memory storage device 1038 may 
take the form of a magnetic or paper tape reader or some other well-known device. It 
will be appreciated that the information retained within the mass memory device 

25 1 038, may, in appropriate cases, be incorporated in standard fashion as part of RAM 
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1036 as virtual memory. A specific primary storage device 1034 such as a CD-ROM 
may also pass data uni-directionally to the CPUs 1032. 

CPUs 1032 are also coupled to one or more input/output devices 1040 that 
may include, but are not limited to, devices such as video monitors, track balls, mice, 

5 keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic 
or paper tape readers, tablets, styluses, voice or handwriting recognizers, or other 
well-known input devices such as, of course, other computers. Finally, CPUs 1032 
optionally may be coupled to a computer or telecommunications network, e.g., an 
Internet network or an intranet network, using a network connection as shown 

10 generally at 1012. With such a network connection, it is contemplated that the CPUs 
1032 might receive information firom the network, or might output information to the 
network in the course of performing the above-described method steps. Such 
information, which is often represented as a sequence of instructions to be executed 
using CPUs 1032, may be received from and outputted to the network, for example, in 

15 the form of a computer data signal embodied in a carrier wave. The above-described 
devices and materials will be famihar to those of skill in the computer hardware and 
software arts. 

As previously mentioned, a virtual machine may execute on computer system 
1030. Fig. 7 is a diagrammatic representation of a virtual machine, which is 

20 supported by computer system 1030 of Fig. 6, and is suitable for implementing the 

present invention. When a computer program, e.g., a computer program written in the 
Java™ programming language, is executed, source code 1 1 10 is provided to a 
compiler 1 120 within compile-time environment 11 05. Compiler 1120 translates 
source code 1110 into bytecodes 1 130. In general, source code 1 1 10 is translated into 

25 bytecodes 11 30 at the time soiirce code 1 1 10 is created by a software developer. 
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Bytecodes 1130 may generally be reproduced, downloaded, or otherwise 
distributed through a network, e.g., network 1012 of Fig. 6, or stored on a storage 
device such as primary storage 1034 of Fig. 6. In the described embodiment, 
bytecodes 1 130 are platform independent. That is, bytecodes 1 130 may be executed 
5 on substantially any computer system that is running on a suitable virtual machine 
1140. 

Bytecodes 1 130 are provided to a runtime environment 1135, which includes 
virtual machine 1 140. Runtime environment 1135 may generally be executed using a 
processor or processors such as CPUs 1032 of Fig. 6. Virtual machine 1 140 includes 

10 a compiler 1 142, an interpreter 1 144, and a runtime system 1 146. Bytecodes 1130 
may be provided either to compiler 1 142 or interpreter 1 144. 

When bytecodes 1 130 are provided to compiler 1 142, methods contained in 
bytecodes 1 130 are compiled into machine instructions. In one embodiment, 
compiler 1 142 is a just- in-time compiler which delays the compilation of methods 

15 contained in bytecodes 1130 until the methods are about to be executed. When 
bytecodes 1130 are provided to interpreter 1 144, b3^ecodes 1 1 30 are read into 
interpreter 1 144 one bytecode at a time. Interpreter 1 144 then performs the operation 
defined by each bytecode as each bytecode is read into interpreter 1 144. That is, 
interpreter 1 144 "interprets" bytecodes 1 130, as will be appreciated by those skilled in 

20 the art. In general, interpreter 1 144 processes bytecodes 1 130 and performs 
operations associated with bytecodes 1130 substantially continuously. 



When a method is invoked by another method, or is invoked from runtime 
environment 1 135, if the method is interpreted, runtime system 1 146 may obtain the 
25 method from runtime environment 1 135 in the form of a sequence of bytecodes 1 130, 
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which may be directly executed by interpreter 1 144. If, on the other hand, the method 
which is invoked is a compiled method which has not been compiled, runtime system 
1 146 also obtains the method from runtime environment 1 135 in the form of a 
sequence of bytecodes 1 130, then may go on to activate compiler 1 142. Compiler 
5 1 1 42 then generates machine instructions from bytecodes 1130, and the resulting 
machine-language instructions may be executed directly by CPUs 1032. La general, 
the machine-language instructions are discarded when virtual machine 1 140 
terminates. The operation of virtual machines or, more particularly, Java™ virtual 
machines, is described in more detail in The Java™ Virtual Machine Specification by 
10 Tim Lindholm and Frank YelUn (ISBN 0-201-63452-X), which is incorporated herein 
by reference. 

While the invention has been particularly shown and described with reference 
to specific embodiments thereof, it will be understood by those skilled in the art that 
changes in the form and details of the disclosed embodiments may be made without 
15 departing from the spirit or scope of the invention. For example, the embodiments 
described above may be implemented using firmware, software, or hardware. 
Moreover, embodiments of the present invention may be employed with a variety of 
communication protocols and should not be restricted to the ones mentioned above. 
Therefore, the scope of the invention should be determined with reference to the 
20 appended claims. 

In summary, the solution presented here is a non-API mechanism for 
bootstrapping a user database (i.e. accepting new user registrations 
from the web-tier) that is consistent with the goals of the J2EE platform, and can also 
be used in many other systems. This mechanism has many of the same advantages as 
25 the API-centric approaches used in the majority of systems today, such as the ability 
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to customize look and feel of the registration form and the ability to prompt for user 

profile data at the same time security data is prompted for. Additionally, it avoids 
many of the disadvantages found in API-centric systems, such as the need 
for the web -application provider to worry about the details of implementing user 

registration, and the need to rewrite portions of application code when new 

authentication mechanisms are introduced. 

What is claimed is: 
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